Effective Android™ malware detection and prevention is a highly sought-after goal of security companies. However, in the Android system, evasive malware is frequently able to easily bypass traditional signature and pattern based detection systems, rendering almost all anti-malware software useless against evolving or new malware threats. Current Android security software relies on the static analysis of application packages. However, such static analysis is known to be ineffective for several reasons. First, malware may update only at runtime and thus, may go undetected using static analysis. Second, malware often uses some form of obfuscation to bypass analysis.
Due to constraints within the Android operating environment, security software deployed on devices running the Android operating system typically rely upon whitelisting or signature based checking while a majority of the Android malware detection is focused on cloud-based or cloud-implemented solutions. GOOGLE® Bouncer is just one example of a cloud based Android malware detection solution. However, malware may escape such sandboxed protection systems using simple strategies such as time delay activation that delays the trigger of malicious behavior and enables the malware after passage of an amount of time sufficient to clear screening.
Android applications consist mainly of Dalvik bytecode. Prior to Android version 4.3 (“Jelly Bean”) the Dalvik bytecode was executed using an interpreter and a just-in-time (JIT) compiler inside Android runtime. Android version 4.4 (“KitKat”) introduced Android Runtime (ART) environment as a technology preview while retaining Dalvik. Beginning with Android version 5.0 (“Lollipop”) ART represented the only included runtime environment. ART uses an interpreter similar to prior Android versions, but introduced the concept of ahead-of-time (AOT) compilation. Android 7 (codename: Nougat) adds just-in-time compilation as well. AOT compilation performs the translation of the application bytecode into native instructions for later execution within the device's runtime environment. Unlike Dalvik, ART is able to compile entire applications into native machine code upon installation on the device.
To maintain backward compatibility, ART uses the same bytecode as Dalvik, supplied via DEX files, while the ODEX files are replaced with executable and linkable format (ELF) executables. Once an application is compiled using ART's on-device dex2oat utility, it runs primarily from the compiled ELF executable.
Although the following Detailed Description will proceed with reference being made to illustrative embodiments, many alternatives, modifications and variations thereof will be apparent to those skilled in the art.